Brought to you by EarthWeb
IT Library Logo

Click Here!
Click Here!


Search the site:
 
EXPERT SEARCH -----
Programming Languages
Databases
Security
Web Services
Network Services
Middleware
Components
Operating Systems
User Interfaces
Groupware & Collaboration
Content Management
Productivity Applications
Hardware
Fun & Games

EarthWeb Direct EarthWeb Direct Fatbrain Auctions Support Source Answers

EarthWeb sites
Crossnodes
Datamation
Developer.com
DICE
EarthWeb.com
EarthWeb Direct
ERP Hub
Gamelan
GoCertify.com
HTMLGoodies
Intranet Journal
IT Knowledge
IT Library
JavaGoodies
JARS
JavaScripts.com
open source IT
RoadCoders
Y2K Info

Previous Table of Contents Next


PUBLIC KEY CERTIFICATES

When a user sends a private E-mail message using the public key cryptography systems available today—for example, privacy enhanced mail (PEM) or Pretty Good Privacy (PGP)—they must obtain the recipient’s public key. For recipients to verify the sender’s electronic signature on a document, they must have the sender’s public key. To obtain someone’s public key, yet be assured that no one has tampered with it (e.g., that a phony key has not been issued to impersonate the sender), systems administrators must accept a public key only if it is certified. Certifying authorities, or trusted third parties, create a certificate by notarizing the key holder’s public key with their signature after validating the key holder’s proof of identity. The certificate is a bond between public key holders and their public key that is vouched for by the certifier.

The validity of public key certificates must be checked before the public keys are used. If the certifier’s signature does not check out, the public key or other parts of the certificate (e.g., the name) have likely been altered. The manner in which trust is conferred to the certifying authority is called a trust model.

PRIVACY ENHANCED MAIL (PEM) AND PRETTY GOOD PRIVACY (PGP)

Two secure E-mail systems are currently being implemented: Privacy Enhanced Mail (PEM) and Pretty Good Privacy (PGP). Each one uses a different trust model to validate certifying authorities. PEM, for example, has a trust model based on a hierarchical structure of certifying authorities.

Privacy Enhanced Mail (PEM)

PEM is the standard proposed by the Internet Engineering Task Force (IETF) that defines procedures for message encryption and authentication services (via digital signatures) for electronic mail transfer on the Internet. PEM is specified by IETF documents RFC1421 - RFC1424.

  RFC1421—Part 1: Message Encryption and Authentication Procedures.
  RFC1422—Part 2: Certificate Based Key Management.
  RFC1423—Part 3: Algorithms, Modes, and Identifiers.
  RFC1424—Part 4: Key Certification and Related Services.

PEM is compliant with the Public Key Cryptography Standards (PKCS) developed by a consortium headed by RSA Data Security, Inc. and several software developers, including Apple, Novell, Lotus, Microsoft, Fischer International, and Sun Microsystems.

PEM is capable of specifying the cipher algorithms it is using. It puts all messages into a canonical form before any cipher or hash operations are performed on them, and ensures that secure E-mail can be interchanged following PEM Internet standards. PEM enables users to do the following:

  Ensure the privacy of their E-mail using a private (symmetric) key cipher algorithm, such as DES.
  Securely distribute symmetric keys using RSA for key encryption.
  Validate public key certificates that are digitally signed using RSA.
  Check message integrity using a hashing algorithm (MD2 or MD5).
  Check digital signatures for authentication or nonrepudiation using RSA on a MD2 or MD5 hash of the message.

PEM messages use unencrypted headers to identify what type of processing was performed and which algorithms were used. The fields in the headers contain more information for the recipient to use when determining the validity of the message, including the public key certificate, the encrypted symmetric key for encoded messages, the message integrity check (MIC) field to indicate the validity of a message and whether it has been digitally signed, and the message itself. The data encryption key, MIC, and the message are encrypted only if indicated in these header fields.

Issuing PEM Public Key Certificates

A certifying authority (CA) can be any trusted central administrator willing to vouch for the identities of those whose keys it certifies. CAs should follow the comprehensive ITU-TSS X.509 standard recommended for certificates and CAs. The CA may be the only party from which to obtain a public-private key pair in certain high-security locations. In a company setting, a potential employee’s information is verified at the time of employment, so usually only employees’ and their managers’ signatures are required on a form. If an employee can generate a public-private key pair, he or she sends the self-signed public key with required proof of identity to an appropriate company CA to be certified. CAs may issue certificates based on varying levels of identification verification of the key holder.

Online CAs are becoming increasingly necessary to satisfy the growing security demands of the information superhighway. Banks and major credit card companies will likely assume this role and issue their own public-private key pairs. These companies may well use identity verification as their sole key certification. Exhibit 8-6-1 presents an example of a PEM hierarchy of certification authority.


Exhibit 8-6-1.  PEM Certification Authority Hierarchy

Determining When PEM Public Keys Are No Longer Valid

PEM keys are deemed invalid in the following instances:

  Before the start date and after the expiration date indicated on their certificates. The dates in a certificate must be checked with the date of the transaction.
  When they have been revoked by the CA and placed on a public list known as the certificate revocation list (CRL). Revocation is detectable only if the party using the public key checks the CRL. The CA should provide this facility or indicate where and how the CRL can be checked.
  When they have been revoked by the key holder or key issuer and placed on a CRL. As previously mentioned, revocation is detectable only if the party needing to use the public key checks the proper CRL. Notably, invalid keys can be used to perform all the operations discussed here. However, a properly designed application should check for and require valid keys.


Previous Table of Contents Next

footer nav
Use of this site is subject certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb, Inc.. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Please read our privacy policy for details.